Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

riscv64: Implement SIMD saturating arithmetic and min/max #6430

Merged
merged 2 commits into from
May 23, 2023

Conversation

afonso360
Copy link
Contributor

👋 Hey,

This PR Implements the saturating arithmetic ({u,s}{add,sub}_sat) and min/max ({u,s}{min,max}) instructions.

Only the saturating arithmetic functions are tested via WASM tests. The min/max instruction testsuites have other instructions mixed in that will be implemented in a future PR so we can't enable them yet. These are currently only tested via cranelift tests.

I've also added i128 tests for min/max since I accidentally disabled these and found we didn't have anything catching that case.

@afonso360 afonso360 requested review from a team as code owners May 22, 2023 18:57
@afonso360 afonso360 requested review from jameysharp and removed request for a team May 22, 2023 18:57
@github-actions github-actions bot added the cranelift Issues related to the Cranelift code generator label May 22, 2023
(vec_alu_rrr (VecAluOpRRR.VminuVV) vs2 vs1 mask vstate))

;; Helper for emitting the `vminu.vx` instruction.
(decl rv_vminu_vx (Reg Reg VecOpMasking VState) Reg)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stray thought, but the x64 backend has different types for Gpr and Xmm which represent a type-level distinction for different classes of registers. I've found that it's actually worked quite well for x64 and it's saved me a few times from mistakes. I realized I should be carefully reading the rules that use *_vx instructions to ensure the variable bound by splat comes second instead of first by accident (since I think that would compile past ISLE but wouldn't get past debug asserts perhaps in the backend).

Having this sort of distinction though is a pretty large refactoring so definitely not necessary on this PR, but perhaps something to consider if you also find yourself trying to carefully ensure each register goes to the right spot.

Copy link
Contributor Author

@afonso360 afonso360 May 23, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that sounds like a good idea! And I've definitely had that happen to me. Not with .vx, but passing an F register into a .vx opcode. We do hit the regclass asserts in the backend, but it would be better to have it as a type system feature.

It should be fairly easy to start at least with the vector rules and helpers. I'm going to give that a try.

@afonso360 afonso360 added this pull request to the merge queue May 23, 2023
Merged via the queue into bytecodealliance:main with commit b4c8509 May 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cranelift Issues related to the Cranelift code generator
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants